Design Block Storage at Scale
The file-sync lesson chunked a file into aligned blocks, hashed each one, and handed the metadata service an ordered list of block hashes. This lesson designs the layer that holds those bytes. It is not a database and it stores no paths or filenames. Its input is a block of at most a few megabytes, keyed by the hash of its contents. It promises that the block is still there years later, and that reading it back returns the exact bytes that went in. Everything interesting here follows from a single decision to make blocks immutable. A block, once written, never changes, so the store never has to reconcile a concurrent edit to the same bytes.
Get the altitude right before drawing a box. This is the block plane from the overview, the huge immutable half that sits under the small transactional metadata half. The metadata service knows a file is a list of hashes; this store knows where each hash physically lives and how many copies or coded shards protect it. Dropbox is unusually public about this system. They moved the bulk of user data off S3 onto their own machines around 2016 and called the result Magic Pocket. They protect it with erasure coding instead of brute-force replication. So the design is won on two questions. How do you get many-nines durability without paying to store every byte three or four times, and how do you place, verify, and reclaim blocks across a fleet that spans regions.
- 1 problem, worked step by step
- 1 diagram
- about 45 min
Premium lessonDropbox interview guide
These took digging.
What candidates walked out with, from 20,000+ reports, forum threads behind logins and write-ups in Chinese. Then solved step by step.
100 companies. Checked every month.
Unlock all 100 companies$49 a year · less than $1 a week · Cancel anytime
Dropbox interview guideKnow what Dropbox asks before you walk in.
16 coding · 5 system design · 23 behavioral questions
Get their questions first.
InterviewLegend is independent and not affiliated with or endorsed by any company it covers.